ETSITS101 759vi.2.i 



(2005-01) 



Technical Specification 



Digital Audio Broadcasting (DAB); 
Data Broadcasting - Transparent Data Channel (TDC) 



European Broadcasting Union 



/ 




Union Europeenne de Radio-Television 



EBUUER 




WBIiSMiJib'flR, ', wSBy 




ETSI TS 101 759 V1.2.1 (2005-01) 



Reference 



RTS/JTC-DAB-33 
Keywords 



audio, broadcasting, DAB, data, digital, packet 
mode 



ETSI 

650 Route des Lucioles 
F-06921 Sophia Antipolis Cedex - FRANCE 

Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 

Siret N ° 348 623 562 0001 7 - NAF 742 C 
Association a but non lucratif enregistree a la 
Sous-Prefecture de Grasse (06) N° 7803/88 



Important notice 



Individual copies of the present document can be downloaded from: 
http://www.etsi.org 

The present document may be made available in more than one electronic version or in print. In any case of existing or 

perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). 

In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive 

within ETSI Secretariat. 

Users of the present document should be aware that the document may be subject to revision or change of status. 

Information on the current status of this and other ETSI documents is available at 

http://portal.etsi.org/tb/status/status.asp 

If you find errors in the present document, please send your comment to one of the following services: 

http://portal.etsi.org/chaircor/ETSI support.asp 

Copyright Notification 

No part may be reproduced except as authorized by written permission. 
The copyright and the foregoing restriction extend to reproduction in all media. 

© European Telecommunications Standards Institute 2005. 

© European Broadcasting Union 2005. 

All rights reserved. 

DECT™, PLUGTESTS™ and UMTS™ are Trade Marks of ETSI registered for the benefit of its Members. 
TIPHON™ and the TIPHON logo are Trade Marks currently being registered by ETSI for the benefit of its Members. 
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners. 



ETSI 



ETSI TS 101 759 V1.2.1 (2005-01) 



Contents 



Intellectual Property Rights 4 

Foreword 4 

Introduction 4 

1 Scope 6 

2 References 6 

3 Abbreviations and syntax specification 6 

3.1 Abbreviations 6 

3.2 Syntax specification 7 

4 Transparent Data Channel specification 7 

4.1 TDC in a packet mode service component 7 

4.1.1 TDC in a packet mode service component without data groups 8 

4.1.2 TDC in a packet mode service component with data groups 9 

4.2 TDC in a stream mode service component 10 

4.3 TDC in an audio service component using X-PAD 11 

4.3.1 TDC in X-PAD without data groups 11 

4.3.1.1 Using short X-PAD for the TDC 11 

4.3.1.2 Using variable length X-PAD for the TDC 12 

4.3.2 TDC in X-PAD with data groups 12 

5 Guidelines for the use of the Transparent Data Channel 13 

History 14 



ETSI 



ETSI TS 101 759 V1.2.1 (2005-01) 



Intellectual Property Rights 
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server ( http://webapp.etsi.org/IPR/home.asp ). 
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Foreword 

This Technical Specification (TS) has been produced by Joint Technical Committee (JTC) Broadcast of the European 
Broadcasting Union (EBU), Comite Europeen de Normalisation ELECtrotechnique (CENELEC) and the European 
Telecommunications Standards Institute (ETSI). 

NOTE 1: The EBU/ETSI JTC Broadcast was established in 1990 to co-ordinate the drafting of standards in the 
specific field of broadcasting and related fields. Since 1995 the JTC Broadcast became a tripartite body 
by including in the Memorandum of Understanding also CENELEC, which is responsible for the 
standardization of radio and television receivers. The EBU is a professional association of broadcasting 
organizations whose work includes the co-ordination of its members' activities in the technical, legal, 
programme-making and programme-exchange domains. The EBU has active members in about 60 
countries in the European broadcasting area; its headquarters is in Geneva. 

European Broadcasting Union 

CH-1218 GRAND SACONNEX (Geneva) 

Switzerland 

Tel: +41 22 717 21 11 

Fax: +4122 717 24 81 

The Eureka Project 147 was established in 1987, with funding from the European Commission, to develop a system for 
the broadcasting of audio and data to fixed, portable or mobile receivers. Their work resulted in the publication of 
European Standard, EN 300 401 [1], for DAB (see note 2) which now has worldwide acceptance. The members of the 
Eureka Project 147 are drawn from broadcasting organizations and telecommunication providers together with 
companies from the professional and consumer electronics industry. 

NOTE 2: DAB is a registered trademark owned by one of the Eureka Project 147 partners. 



Introduction 



The Transparent Data Channel (TDC) specification provides DAB with the ability to transport simple data streams 
using a variety DAB data channels. In a simple stream, data bytes are processed sequentially by the receiver in the order 
in which they are received but there is no implied beginning or end to the data. Any "framing" of data within the stream 
is determined purely by the application protocol that is carried by the stream. 

Three forms of the Transparent Data Channel are specified here: 

• TDC in a packet mode service component; 

• TDC in a stream mode service component; 

• TDC in an audio service component carried as X-PAD. 
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The Transparent Data Channel complements the MOT specification by allowing DAB to transport data in the form of 
streams as well as files. It is intended that applications that rely on simple stream transport, such as the TPEG and 
DGPS protocols, can be supported in DAB simply by specifying the use of the Transparent Data Channel for data 
transport. 

The present document has removed the "byte stuffing" mechanism previously defined for TDC carried as X-PAD as 
this was found to cause some decoding difficulties. In addition, data groups may be used in X-PAD. 
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Scope 



The present document specifies how to transport data transparently within the Digital Audio Broadcasting (DAB) 
system forming a Transparent Data Channel (TDC) and gives guidelines for its use. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 



HI 



[3] 



ETSI EN 300 401: "Radio Broadcasting Systems; Digital Audio Broadcasting (DAB) to mobile, 
portable and fixed receivers". 



[2] ETSI TR 101 496 (all parts): "Digital Audio Broadcasting (DAB); Guidelines and rules for 

implementation and operation". 



ETSI EN 301 234: "Digital Audio Broadcasting (DAB); Multimedia Object Transfer (MOT) 
protocol". 



3.1 



Abbreviations and syntax specification 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

CCITT International Consultative Committee for Telegraph and Telephone 

CRC Cyclic Redundancy Check 

DAB Digital Audio Broadcasting 

F-PAD Fixed - Programme Associated Data 

MOT Multimedia Object Transfer 

MSC Main Service Channel 

PAD Programme Associated Data 

TCP Transmission Control Protocol 

TDC Transparent Data Channel 

TPEG Transport Protocol Experts Group 

X-PAD eXtended - Programme Associated Data 
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3.2 Syntax specification 



The specifications of syntax that appear in the present document are written using a form of pseudo-code that is similar 
to the procedural language "C"; this provides for easy specification of loops and conditional data structures. Within 
these specifications, the type of individual data fields is expressed using the mnemonics given in table 1-1. 

Table 1-1 : Data type mnemonics for syntax specification 



Mnemonic 


Description 


uimsbf 


Unsigned integer, most significant bit first 


bslbf 


Bit string, left bit first 


rpchof 


Remainder polynomial coefficients, high order first 



4 Transparent Data Channel specification 

The MOT protocol allows transportation of objects - this is achieved either by using simple MOT transport for 
non-ordered data objects or by using a data carousel for a managed set of data files. As a complement to this, the 
Transparent Data Channel allows simple stream data to be delivered to support stream based applications (for example 
TPEG). 

The TDC specification described below is based on the mechanisms that are provided by EN 300 401 [1] for data 
delivery: 

• Packet mode service component. 

• Data in an audio service Component using X-PAD. 

The implementation of these basic mechanisms is explained in more details in TR 101 496 [2]. 

4.1 TDC in a packet mode service component 

TDC data carried in a packet mode service component may be organized either with or without the MSC data group 
structure defined by EN 300 401 [1]. 

The use of data groups for establishing a transparent data channel provides: 

• Error control by using data group repetition. 

• The ability to guarantee that "chunks" of data from the stream are delivered to the receiver (or lost) as a 
coherent sets of data. 

• Optional addressing of end users. 

Where the features above are not required, not using data groups for the TDC provides: 

• Low overhead. 

• Low latency. 

• Simple processing requirements. 

The two forms of the TDC in a packet mode service component are specified in the following paragraphs. 
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4.1 .1 TDC in a packet mode service component without data groups 

Packet mode sub-channels use a simple packet protocol to allow a number of separate data services to be multiplexed 
into a single DAB sub-channel. Carriage of simple stream data in such a channel is implemented by sending packets 
containing the data when there is data to send. The structure of DAB packets is shown in table 2-1. 

Table 2-1 : Structure of a DAB packet 



Syntax 


Size 


Type 


DAB_packet ( ) { 






packetlength 


2 bits 


uimsbf 


continuityindex 


2 bits 


uimsbf 


first_ flag 


1 bit 


bslbf 


last flag 


1 bit 


bslbf 


packet address 


10 bits 


uimsbf 


command_flag 


1 bit 


bslbf 


useful_data length 


7 bits 


uimsbf 


for (i=0; i<useful_data_length; i++) { 






packet dat a by t e 


8 bits 


uimsbf 


s 

for (i=0; i<N; i++) { 






padding_byte 

\ 


8 bits 


uimsbf 


i 
packet_CRC 

} 


16 bits 


rpchof 



packetjength: This field can take one of four values to indicate the overall size of the packet in multiples of 24 bytes. 
The maximum length of the payload of each packet is equal to the overall packet length minus the 5 bytes of packet 
overhead. The overall packet length may be determined from the packet_length field by the formula 
(packet_length + 1) x 24, thus a packet_length of indicates an overall packet length of 24 bytes and a packet _length of 
3 indicates an overall packet length of 96 bytes. 

continuity_index: The continuity _index is incremented by one for each successive packet that is sent for a particular 
packet _address . 

first_flag: The first _flag is used to indicate (when set to 1) that the packet is the first packet in a series of packets that 
are to be assembled into an MSC data group. 

last_flag: The lastjlag is used to indicate (when set to 1) that the packet is the last packet in a series of packets that are 
to be assembled into an MSC data group. 

packet_address: The packet _address is a 10 bit number that identifies packets for a particular data service component 
within the multiplex of components for a packet mode sub-channel. 

useful_data_length: The useful_data_length field identifies the number of bytes within the payload of the packet that 
are to be considered to be carrying useful data. 

packet_data_byte: These fields carry the useful payload for each individual packet. 

paddingjbyte: The padding_bytes are used to fill the remainder of the packet after the packet _data_bytes and shall be 
set to 0. 

packet_CRC: The packet _CRC field is calculated, according to the CCITT CRC-16 polynomial, over the entire packet, 
with the CRC register initialized to all Is and the resulting CRC inverted. 

Within a packet mode sub-channel, packets may be assembled into larger, variable length datagrams known as MSC 
data groups. The assembly of packets into data groups is controlled by the first and last flags, as shown in table 2-2. 
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Table 2-2: Interpretation of first and last flags 



firsMlag 


last_flag 


Interpretation 




1 
1 



1 

1 


The packet is an intermediate packet in a series of packets 
The packet is the last packet in a series of packets 
The packet is the first packet in a series of packets 
The packet is the one and only packet 



In order to carry stream data in this very simple way, the data is sent in packets with the first_flag and the last_flag both 
set to zero, thus indicating that the data carried by the packets is simply an intermediate part of a stream with no specific 
start or end. Marking the packets in this way ensures that no receiver will ever attempt to incorrectly assemble 
asynchronous stream data into data groups. 

The use of data groups in TDC depends upon the DG flag in FIG 0/3 (see EN 300 401 [1]). When set to '0', data groups 
are used, when set to T no data groups are used. 

4.1 .2 TDC in a packet mode service component with data groups 

In order to carry stream data, the data is put into a data group, which in turn is sent in packets. 

Table 2-3: Structure of an MSC data group 



Syntax 


Size 


Type 


MSC_data_group() { 






MSC_data_group_header ( ) { 






extension flag 


1 


bslbf 


CRC_flag 


1 


bslbf 


segmentflag 


1 


bslbf 


user_access_flag 


1 


bslbf 


data_group_type 


4 


uimsbf 


continuity index 


4 


uimsbf 


repetitionindex 


4 


uimsbf 


if (extension_f lag == 1) { 






extensionfield 

} 


16 


bslbf 


} 

session_header () { 






if (segment_f lag == 1) { 






last 


1 


bslbf 


segmentnumber 

} 


15 


uimsbf 


if (user_access_f lag == 1) { 






user_accessj ield () { 






rfa 


3 


bslbf 


tranport_id_flag 


1 


bslbf 


length indicator 


4 


uimsbf 


if (transport_id_f lag ==1) { 






transport_id 

\ 


16 


uimsbf 


i 

end_user_address_f ield ( ) { 






for (n=0; n<length_indicator-2 ; n++) { 






end user address byte 

} 
} 
} 


8 


uimsbf 


} 
} 

MSC_data_group_data_field() { 






for (i=0; i<data_group_length; i++) { 






data group data byte 

} 
} 


8 bits 


uimsbf 
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Syntax 


Size 


Type 


if (CRC_flag==l) { 

MSC_data_group_CRC 

} 
} 


16 bits 


rpchof 



extension_flag: The extension _Jlag indicates (when set to 1) that the extension Jield is present. 

crc_flag: The crc_flag indicates (when set to 1) that the MSC_data_group_CRC is present. 

segment_flag: The segment Jag indicates (when set to 1) that the segment_number and last Flag in the session_header 
are present. 

user_access_flag: The user_accessjlag indicates (when set to 1) that the user _access Jield in the sessionjieader is 
present. 

data_group_type: For TDC the data_group_type shall be set to 0. 

continuity_index: The continuity _index shall be incremented each time a data group with a content different from that 
of the preceding data group is transmitted. 

repetition_index: The repetition_index shall signal the remaining number of repetitions of a data group with the same 
content. Exceptionally, the code Till' shall be used to signal that the repetition continues for an undefined period. 

extension_field: The extension Jield is reserved for future use in TDC. 

last: The last flag shall indicate that the current data group is the last in a sequence of data groups with the same 
transported that carry the data for a coherent "chunk" of data from the TDC. 

segment_number: The segment_number shall indicate the segment number of the current data group when a coherent 
"chunk" of data (identified by the transported) is being transmitted that is longer than a single data group. 

rfa: Reserved for future additions. Shall be set to '0'. 

transport_id_flag: For TDC, the transported Jag shall indicate (when set to 1) that the transported field is present. 

length_indicator: The length endicator shall indicate the length n in bytes of the transported and the 
end _user_address Jield. 

transported: For TDC, the transported (if needed) shall be identical for all different segments forming a specific 
"chunk". It shall be changed for each coherent "chunk" of data. 

end_user_address_byte: The end_user _address Jytes shall be used to distinguish between different TDC data streams 
for different terminals. Its use depends upon the application (Application^ in FIG0/13) and is not subject to the present 
document. 

MSC_data_group_data_byte: The MSC_data_group_data_bytes shall contain the data for the transparent data 
channel. 

MSC_data_group_CRC: The MSC_data_group_CRC field is calculated, according to the CCITT CRC-16 
polynomial, over the MSC_data_group_header, the sessionjieader and the MSC_data_group_data Jield, with the 
CRC register initialized to all Is and the resulting CRC inverted. 

4.2 TDC in a stream mode service component 

In a stream mode service component, all the data for the sub-channel is assumed to be part of the stream. This means 
that a Transparent Data Channel carried in a stream mode service component is an essentially synchronous (i.e. fixed bit 
rate) stream. 
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4.3 TDC in an audio service component using X-PAD 

TDC data carried in X-PAD may be organized either with or without the MSC data group structure defined by 
EN 300 401 [1]. 

The use of data groups for establishing a transparent data channel provides: 

• Error control by using data group repetition. 

• The ability to guarantee that "chunks" of data from the stream are delivered to the receiver (or lost) as a 
coherent sets of data. 

• Optional addressing of end users. 

Where the features above are not required, not using data groups for the TDC provides: 

• Low overhead. 

• Low latency. 

• Simple processing requirements. 

The two forms of the TDC in X-PAD are specified in the following clauses. 

Two forms of X-PAD are available and the precise interpretation of the X-PAD sub-field for the TDC depends on the 
type of X-PAD that is being used. In "short" X-PAD, a single field of either 3 bytes or 4 bytes is present in each audio 
frame. In "variable length" X-PAD, up to four X-PAD sub-fields of up to 48 bytes each can be present in each audio 
frame. The two cases are described in detail below. 

4.3.1 TDC in X-PAD without data groups 

X-PAD uses a simple protocol to allow a number of separate data services to be multiplexed into a single DAB 
sub-channel. Carriage of simple stream data in such a channel is implemented by sending data when there is data to 
send. 

In order to carry stream data in this very simple way, the data is sent without a beginning or an end. Thus, only one 
X-PAD application type is required for each User Application using the "Transparent Data Channel" 
(see EN 300 401 [1], clause 7.4.3) to identify the X-PAD data subfields carrying TDC data. The X-PAD application 
type used is signalled using FIG 0/13. 



4.3.1.1 



Using short X-PAD for the TDC 



Table 2-4 shows the structure of short X-PAD but it should be noted that the byte order of the X-PAD fields is reversed 
on transmission. See EN 300 401 [1] for more details. 

Table 2-4: Structure of X-PAD when using short X-PAD 



Syntax 


Size 


Type 


Value 


X-PAD_field() { 










if (contents_indicator_f lag = 


= 1) { 








applicationtype 




8 bits 


uimsbf 




X-PAD_subfield 




24 bits 


uimsbf 




} else { 










X-PAD_subfield 

} 
} 




32 bits 


uimsbf 





contents_indicator_flag: This flag is identical with the CI flag in F-PAD (see EN 300 401 [1]) and is used to indicate 
the presence of a contents_indicator field in the same DAB audio frame. 

application_type: This field determines the intended application for the X-PAD_subfield in conjunction with FIG 0/13. 

X-PAD subfield: This field carries the stream data for the TDC. 
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4.3.1.2 



Using variable length X-PAD for the TDC 



Table 2-5 shows the structure of variable length X-PAD but it should be noted that the byte order of the X-PAD fields is 
reversed on transmission. It also should be noted, that in addition to the table, a complete X-PAD field may comprise a 
single data subfield (provided the X-PAD field is containing a continuation of the X-PAD data application of the same 
type as that carried in the last X-PAD data subfield of the previous DAB audio frame). For details see EN 300 401 [1] 
and TR 101 496 [2]. 

Table 2-5: Structure of X-PAD when using variable length X-PAD 



Syntax 


Size 


Type 


Value 


X-PAD_field() { 








if (contents_indicator_f lag == 1) { 








for (i=0;i<Nl;i++) { 








X-PAD_subfield_length 


3 bits 


bslbf 




application_type 


5 bits 


uimsbf 




if (application_type == 31) { 








application type extension 

} 
} 


8 bits 


uimsbf 




} 

for (i=0;i<Nl;i++) { 








for ( j = 0; i<X-PAD_subfield_length (Nl) ; j + +) { 








X-P AD„dat a_by t e 

} 
} 
} 


8 bits 


uimsbf 





contents_indicator_flag: This flag is identical to the CI flag in F-PAD (see EN 300 401 [1]) and is used to indicate the 
presence of a contents_indicator field in the same DAB audio frame. 

X-PAD_subfield_length: This field determines the length the X-PAD_subfield. 

application_type: This field determines the intended application for the X-PAD_subfield in conjunction with FIG 0/13. 

application_type_extension: This field determines the intended application for the X-PAD_subfield when the 
application type is set to 3 1 . 

X-PAD_data_byte: These fields carry the data for the X-PAD sub-field. 

4.3.2 TDC in X-PAD with data groups 

X-PAD uses a simple protocol to allow a number of separate data services to be multiplexed into a single DAB 
sub-channel. Carriage of simple stream data in such a channel is implemented by sending data when there is data to 
send. 

In order to carry stream data, the data is put into MSC data groups, which in turn are sent in X-PAD data groups 
(see EN 300 401 [1], clause 7.4.5). Thus, two X-PAD application types (start and continuation) are required for each 
User Application using the "Transparent Data Channel" (see EN 300 401 [1], clause 7.4.3) to identify the X-PAD data 
subfields carrying TDC data. The X-PAD application types used are signalled using FIG 0/13. 

The structure of the data group carrying TDC data is exactly the same as for "TDC in a packet mode service component 
with data groups" (see clause 4.1.2) and the data groups may be carried in either short X-PAD or variable length 
X-PAD. 
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5 Guidelines for the use of the Transparent Data 

Channel 

Simple stream data formats are extremely common, not least because the bulk of Internet communication uses stream 
transport in the form of TCP/IP. When defining applications to use the DAB Transparent Data Channel, however, it is 
important to recognize that there are differences between streams implemented using TCP/IP and broadcast streams. 

In TCP/IP, a series of acknowledgements and time-outs is used to detect and correct any errors that are introduced into 
the data for the stream. This means that reliable delivery of the data is guaranteed but this feature relies on the fact that 
the Internet allows bi-directional communication. In a broadcast environment there is no possibility for a receiver to 
request re-transmission of data that has been corrupted, and so it is not possible to guarantee reliable delivery of data 
using the DAB Transparent Data Channel. 

Because reliable delivery of data cannot be assumed, applications that use the Transparent Data Channel for data 
transport must ensure that they are tolerant to errors in the data. This applies to corrupted data, loss of data and 
additional erroneous data. 

The TDC specification is based on two mechanisms provided by EN 300 401 [1] for data delivery, either delivery in a 
packet mode service component or in an audio service component using X-PAD. So the specification enables each 
service provider to whom only one single type of service component is assigned by regulation authorities, to take the 
appropriate mechanism. 

In case of an audio service component using X-PAD the TDC specification offers a single, but very simple delivery 
mechanism. 

In case of a packet mode service component there are three options to be chosen from. Which of the options will be 
chosen has to be determined by the definition of the application, depending on its requirements in terms of performance 
and complexity, particularly in terms of storage capacity and error robustness. The options are: 

• The TDC in a packet mode component without data groups is a very simple delivery mechanism, as simple as 
the TDC in an audio service component. 

• If the TDC is using data groups in packet mode, but without any session header, TDC provides the possibility 
to retransmit the same data group one or several times, so that a receiver can cope with bit errors in one or the 
other data group. It is recommended that the data group is restricted to a size of 8 kBytes. This ensures, that 
under normal reception conditions the error probability for a data group can be kept low and that further on, 
the storage capacity is in line with a more advanced receiver design. The same restriction applies when a 
session header is used with end user address field only. 

• If the TDC is used with data groups including session headers, it is capable to deliver "chunks" of data. As 
with a multimedia object (see MOT protocol - EN 301 234 [3]) a chunk is segmented in data groups of equal 
size. Each segment of a chunk is identified by its segment number. All segments of a particular chunk are 
identified by the same Transportld. 

If an application uses the TDC delivery in packet mode, it should use the method with the lowest complexity that 
complies with the required performance. 

The TDC delivery of chunks is included in the present document for completeness and with the intention to provide 
future proof mechanisms. 
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